SuperHack

home *** CD-ROM | disk | FTP | other *** search

/ SuperHack / SuperHack CD.bin / CODING / DEMOS / DEMONEW5.ZIP / DEMONEWS.137

Wrap

Text File | 1997-01-06 | 46.9 KB | 1,005 lines

______/\__________________________ __ ________________ ___ /\_______ \____ \ ________ _ _ ______ \ / \| \ ________ | \/ ______/ / | \ _) \ \_/ \ | \ / \ \ _) \ | \______ \ / | \ \ | \ | \ / \ \ / \ \ / \ \_____ /_______/___| /_______/ \____\_____/_______/_________/________/ \_____/ |____/ Subscribers : 2618 DemoNews 137 - 21 December 1996 Archive Size : 3683M >------------------------------------------------------------------ Contents -- Introduction Calendar Top Downloads New Uploads Articles Software Design for Demos ..................... Kiwidog Ratings - What Does It All Mean? .............. Phoenix NAID - Memories ............................... White Noise Java and Demos ................................ 3NO Hornet Archive And Jukebox Truth .............. David Greenman A Demo Scene Survey ........................... Nick The #trax Page ................................ b0b General Information >-------------------------------------------------------------- Introduction -- Ho ho ho, and welcome to DemoNews 137. _____Introduction [Note: I will be on vacation from 21-29 of December.] 1997 is about 10 days away. It's time to buy a new calendar and give the old one to the packrat in the family. Everyone seems focused on Christmas and the passage of another year. And why not? A "year" is a really nice chunk of time. It's long enough to define an era of the demo scene, yet short enough not to obscure memories of previous years. So what does 1997 mean to me? mkdir /demos/1997 mkdir /music/songs/1997 mkdir /graphics/images/1997 ... :D I've been contributing to the scene since 1992. There are others out there who have been around longer but their number is small and becoming more so. However, as a result of the roles I've had in the scene I feel I have a unique perspective on things. I'd like to share some history and future predictions. _____The Past Since I wasn't in the PC scene until 1992 I can't really talk about things before then. I do know that in 1992 things were drastically different then they are now. A soundcard was a totally cool _optional_ component of your system. Demos almost always outshined games in terms of technology and innovation. There was no web. The Internet was still a buzzword to most of the scene. In September, Dan Wright started the Hornet Archive and DemoNews. 1993 brought the scene a GUS and a new standard. People started jumping on the 'net and sending international email without even logging onto a BBS! And with that change a lot of localization in the scene fell to the wayside... national scenes turned into continental ones. Connectivity brought us faster access to new releases around the world. Second Reality came out and a new generation of demo enthusiasts were born. I personally consider 1993 to be the best year in modern PC demos history. 1994 was like 1993++. More people hopped online. PC hardware was finally getting consistent. You could on people in the scene having a 486 and a SB and/or GUS. The music scene was starting to take off and become almost another entity. Everyone still knew how to navigate in DOS. Trying to run demos under Windows 3.1 was laughable. People usually belonged to one group. IRC was a very nice size and mostly cool people hung out there. Then came 1995. You could count on almost everyone having an email address and net connectivity. Demo parties started popping up everywhere. There was explosive growth everywhere. Unfortunately, demos were starting to lose their technological edge and public appeal. The masses who would have dropped their jaw at Second Reality in 1993 were bored to tears with Dope. The scene started to see the death of DOS in sight and were confused. What OS to go to next? Windows 95, Linux, or something new? Earlier this year I think the scene pretty much decided to stick with Windows 95, for better or worse. No longer could you count on people understanding DOS or being as resourceful as they were in 1993-1994. A huge influx of newbies appeared in the music scene. The BBS's have all but died and everyone and their kid sister creates web pages. I used to give presentations at local computer clubs and high schools about the demo scene. The audience used to be captivated that such things existed. Those same people today are more interested in Bevis and Butthead AVIs, obscene WAV files, and Java applets that crash '95 than they are about demos. This is sad. _____The Future Today the scene is thinking about moving from DOS to Java (how odd that sounds). I see this move as having one of two different outcomes. First, we can rekindle some of the innovation and creativity we used to have and totally stun the world with our productions. Or second, we get lumped into a general category: pretty cool Java applet makers. I hope for the first but expect the second. :( All is not lost though. One really neat thing the scene has is the ability to earmark its members. Even though the public has found our secret little world and invaded it, we still know who is _really_ in the scene and who isn't. And it isn't a fuzzy distinction. You either are in the scene or you aren't. We know no middle ground. I'm happy that this aspect of the scene hasn't changed. It gives us a nice, solid, protective buffer from the outside world. Predictions? I'm really hesitant to make any strong ones. I do know that the scene is volatile and changing dramatically. This is not a statement I would have made at the end of any other year except for 1996. 1997 will affect the very core of the scene... what OS we support, how we deal with the public (or avoid them), the death of the GUS standard, the commercial invasion, newbies who are totally lacking in basic skills, etc. _____Conclusion Of one thing I am certain. 1997 will define a new era of the demo scene. Snowman / Hornet - r3cgm@hornet.org >------------------------------------------------------------------ Calendar -- Date Event Location Contact Points ------------ ------------------- --------- ---------------------------------- CANCELED! Demobit Slovakia demobit@elf.stuba.sk internet.sk/demobit/english.htm CANCELED! Tesko UK party@tesko.demon.co.uk 09 Dec 1996 Movement Israel civax@kinneret.com * <-- YOU ARE HERE 27 Dec 1996 The Party 6 Denmark theparty@vip.cybercity.dk www.theparty.dk 15 Feb 1997 General Probe 3 Poland s146630@ire.pw.edu.pl 28 Mar 1997 Mekka & Symposium Germany amable@aol.com 04 Apr 1997 X Takeover Holland x97take@freemail.nl 12 May 1997 The Place To Be 4 France www.mygale.org/05/dadu 22 Aug 1997 AntIQ Hungary aboy@ttk.jpte.hu www.jpte.hu/~aboy >------------------------------------------------------------- Top Downloads -- This represents combined ftp/http transfers for the last 7 days. Sorry, my "get description" subroutine broke and I didn't have time to fix it before these statistics were generated. Total files downloaded : 182,943 Size of files downloaded : 27,130,504k Times File Description ----- -------------------------------- -------------------------------------- -- /demos ------------------------------------------------------------------> 198 /demos/1995/a/animate.zip 155 /demos/1995/n/nooon_st.zip 135 /demos/1993/u/unreal11.zip 126 /demos/1993/s/symbolog.zip 119 /demos/1996/a/ai_strok.zip 118 /demos/1993/0-9/2ndreal1.lzh 114 /demos/1996/p/paper.zip 113 /demos/1996/m/machines.arj 109 /demos/1993/0-9/2ndreal2.lzh 108 /demos/1996/m/machines.a01 -- /music ------------------------------------------------------------------> 100 /music/songs/1995/s3m/a/aryx.zip 76 /music/songs/1996/s3m/a/athought.zip 66 /music/songs/1996/s3m/i/im_chron.zip 60 /music/songs/1996/s3m/i/im_empir.zip 59 /music/songs/1996/xm/r/raf-bost.zip 56 /music/songs/1996/s3m/f/fm-mech8.zip 56 /music/songs/1995/s3m/c/ctgoblin.zip 55 /music/songs/1996/s3m/f/fa-bung.zip 51 /music/songs/1996/s3m/c/ccs-eps.zip 50 /music/songs/1996/xm/a/anthem.zip -- /graphics ---------------------------------------------------------------> 18 /graphics/images/1996/c/chantal.zip 17 /graphics/images/1994/i/incest5.zip 16 /graphics/images/1996/a/airwar.zip 13 /graphics/images/1996/a/abc_land.zip 12 /graphics/images/1996/i/impcybor.zip 12 /graphics/images/1996/a/abc_pien.zip 12 /graphics/images/1996/0-9/3dots.zip 12 /graphics/disks/1996/pls_wild.zip 11 /graphics/images/1996/v/voyeur.zip 11 /graphics/images/1996/s/scarlet.zip -- /code -------------------------------------------------------------------> 81 /code/effects/3d/3dtext.arj 75 /code/effects/3d/fh-3dt18.zip 74 /code/tutor/tut21.zip 73 /code/effects/tunnel/araidsrc.zip 68 /code/effects/rotozoom/pasroto.zip 67 /code/effects/blobs/blobs.zip 66 /code/effects/vector/rn_vect.zip 66 /code/effects/phong/mphong.zip 65 /code/effects/voxel/voxeltut.zip 64 /code/effects/wormhole/stargate.zip -- /incoming ---------------------------------------------------------------> 64 /incoming/music/disks/fm-plast.zip 62 /incoming/music/songs/xm/t2.zip 55 /incoming/mags/sub00004.zip 53 /incoming/demos/astralf.zip 52 /incoming/code/chaossrc.zip 50 /incoming/demos/riplview.zip 49 /incoming/music/disks/u-lucid3.zip 48 /incoming/code/dos32vbe.zip 47 /incoming/demos/1k_intro.zip >--------------------------------------------------------------- New Uploads -- All ratings are subjective. Filename Size Rated Description ------------------------------- ---- ----- ---------------------------------- -- /demos ------------------------------------------------------------------> /1996/0-9/1stepfix.zip 7 ** CAC96B:in4k:??: The First Step by | Brave Lamers /1996/a/abc_voda.zip 808 *** Voodka by Absence /1996/a/ai_mutha.zip 936 ***+ CAC96B:demo:01: Mutha by Astroidea /1996/a/amitro.zip 4 + Amitro by Damage PC /1996/a/ashes.zip 65 ** Ashes by Tate /1996/b/booth.zip 274 ** SEN96:demo:??: Booth by MFX /1996/b/br-1st.zip 841 [n/a] CAC96B:demo:??: First by Black | Rainbow /1996/c/clx_nog.zip 2802 *** SEN96:demo:??: No Garden by | Complex /1996/c/cob.zip 67 **** SAT96B:in64:12: Cob by Nooon, | Orange /1996/c/comahomo.zip 567 **+ SEN96:demo:03: Homo by COMA /1996/d/dem3sat4.zip 404 *+ SAT96B:demo:06: Tartofraise by | Horizone /1996/d/dny-inac.zip 70 *** CAC96B:in64:??: In Activity by | Dinasty /1996/e/elite.zip 274 * The Elite Demo by Intra /1996/e/explora.zip 1509 ***+ SAT96B:demo:02: Explora by Bomb, | Oxygene /1996/f/fade.zip 59 *** CAC96B:in64:??: Fade by Exact /1996/f/fastark.zip 1283 *** SAT96B:demo:03: Fast by Arkham /1996/f/fg-porno.zip 463 + CAC96B:demo:??: Porno by Firg /1996/f/fizzygay.zip 61 **+ SEN96:in64:??: Peter and I Like | Fizzy Water... by TPOLM /1996/f/frs_clue.zip 78 **+ CAC96B:in64:??: Clue by Fresh /1996/g/grd_eqtn.zip 58 **+ Equation by The Grid /1996/h/h_empty.zip 66 ***+ SEN96:in64:01: Empty by Halcyon /1996/i/io3_4k.zip 15 Intel Outside 3 4k Intro Compo | Entries /1996/k/kala.zip 1419 [n/a] SEN96:demo:??: Kalanviljelylaitos | by Tempest /1996/m/mantmag.zip 2084 ***+ SAT96B:demo:01: Magma by Mentasm /1996/m/muna.zip 1053 * SEN96:demo:01: Muna by Hirmu /1996/n/ntl.zip 81 ** SAT96B:in64:06: Not Too Late by | Skytech Group /1996/p/p-statio.zip 71 *** SEN96:in64:??: Station A. Hoffman | by Paragon /1996/p/pastel.zip 19 **+ CAC96B:in4k:??: Pastel by | Controlled Dreams /1996/p/pearl.zip 60 *** Pearl by Poison /1996/p/pierre2.zip 910 [n/a] SEN96:demo:??: Pierre Deux by Coon /1996/p/probe.zip 602 *** CAC96B:demo:03: Probe by | Euthanasia /1996/r/ravetro.zip 69 **+ CAC96B:in64:??: Ravetro by Byteam /1996/s/sat_ast.zip 223 *+ SAT96B:demo:05: Narguileh by AST | System /1996/s/sck-onyx.zip 1546 ***+ CAC96B:demo:02: Onyx by Shock /1996/s/sphere.zip 76 ***+ CAC96B:in64:01: Sphere by Mortal | Compact /1996/s/ste-08.zip 123 *+ N0ll 8tta by Syntax Terror /1996/s/ste-die.zip 111 * Doo by Syntax Terror /1996/s/ste-stlf.zip 423 ** REM96:demo:04: Don't Get Stajlish | (final) by Syntax Terror /1996/s/super_.zip 691 **+ SEN96:demo:02: Superman's Day Out | by TPOLM /1996/t/talo.zip 116 * SEN96:demo:??: Talo by P33107 /1996/t/the_cube.zip 19 *** CAC96B:in4k:01: The Cube by Fishy /1996/t/tls_time.zip 580 *** Time by The Lost Souls /1996/u/uf_depr.zip 1295 ** CAC96B:demo:??: Depravity by | United Force -- /party ------------------------------------------------------------------> /invites/1996/cache96a.zip 532 [n/a] CAC96B::: Cache '96 Autumn | Invitation Intro by Unicorn /invites/1996/demol2.zip 216 *** DML96B::: Demolition II '96 | Invitation Intro by Ws, Solen /reports/1996/p2b4_myo.zip 3516 ** The Place To Be IV Slideshow by | Myopath Crew /results/1996/cac96a.res 0 CAC96B::: Cache '96 Autumn Results /results/1996/cov96res.txt 3 COV96::: Coven '96 Results /results/1996/w96res.zip 4 WIR96::: Wired '96 Results >------------------------------------------------------------------ Articles -- ----------------------------------------------------------------------------> :: "Software Design for Demos" :: Kiwidog - chargrove@mail.ravensoft.com _____Introduction Hello everyone. :) As I wrap up the Intro to 3D series in extremely late fashion in my spare time, I've decided to start writing another article series on a topic not talked about very often in demo coding... software design. This has been a somewhat touchy subject because good coding design practices are hard to learn in an environment where ultra-rapid speed is all that counts, and where the coders typically are self-taught individuals in their late teens to early twenties. From what I've seen, there are three prevalent views among demo coders I've talked to; they either A) think good coding practices necessitate intolerably slow code, B) think good coding practices require unnecessary effort when writing demo code, and/or C) think taking the time to learn good coding practices wouldn't have much benefit as far as demos go. While B may be true depending on your situation, A and C are most definitely myths, and I think these myths are slowly contributing to the scene's gradual "falling behind" as far as innovations go. The times of making tiny single routines that look super-impressive to everyone are over, and making large demos that have impact is getting more and more difficult with time. As a result, people are either making crappy or unoriginal demos (such as the 3D-engine-object-show rut), or even worse, not making demos at all... and the scene is losing its edge because of it. For the past 5 months or so, I've been employed at Raven Software, a game company whose games you've worst case seen on the shelves, best case played and enjoyed (I'm not going to plug the company since this is not a sponsored article, but you knew I'd bring them up somewhere :) In these 5 months I've ended up learning more than I could possibly fathom previously about writing good code. Not just fast code or small code.... _good_ code. If you don't know what that means, you haven't had to deal with the frustration of coding a large project, and if you think you know what it means and think it's not as "good" really because it means bloated and slow, you're wrong. I think that if demo coders took the time to learn some good coding practices and software design, it would not only allow them to focus more on the demos themselves, but would also give them more power to really do in demos what they enjoy doing the most... creating. If you're spending forever trying to get your code to work with your teammates' code, or if you find yourself rewriting your VGA unit every month, that's time taken away from the fun part, the creating. In addition, for those of you that are thinking of bringing your programming skills into the outside world, good software design skills are a huge plus (I'm not saying this as a prospective employer, as I'm not... I'm saying this as a fellow coder who wishes he could have learned 2 years ago what he's learned in the past few months, as it would have been incredibly helpful). If the scene's going to get out of its rut and continue to move on to bigger-better-faster things, it's also got to add one more property to the list... smarter. Without coding smarter, coding faster won't do you any good once the project gets intense. So that's what this series is about. In this article series I'm going to show you how to start creating a comprehensive demo library and development system, which I am working on myself only shortly before these articles are being written. We'll build this development system from the ground up, and in the end you'll be able to take the practices used and move them over into your own code, whatever your language or compiler may be. This is not a rigid "cut and paste my code and you will code perfect demos" thing by any means; at the time of this writing I'm still working on making a full demo, so I can't speak for this stuff being gospel (actually it can most certainly be improved). But I think it's the _principles_ that are important, and those don't change regardless of what language you prefer or how fast your texture mapping algo is. Think of it as a "helpful hints" type of thing. :) The key points I'll be going over during this whole shindig: - Good naming conventions - Organization for large projects - Code Re-Use along with a couple demo-specific things that I've found useful, such as process queues (fake multitasking for effects) and internal consoles for on-line development. This is not a basic intro series like I did last time; this is a bit more high up. Not _too_ high up, but a bit more than before. To really gain from these articles you'll probably have had to have had frustrations in the past with large project organization (I could name a certain person from Psychic Monks that would fit this category from this past NAID, but he already knows who he is :) Trust me, I've had just as much frustration, so you're not alone. _____Dammit Kiwi! Here's the part where I'm sure there will be a lot of coders screaming "DAMMIT KIWI!", and before you do, read the whole section. The language of choice for me to write the code for this series is C++. If you find yourself screaming "Demos using C++? What the hell is he thinking? C++ is bloated and slow, it's what you write Windows programs with, not demos! This sucks!", then perhaps reality will set in when you see that C++ code overhead is.... well.... Zilch. That's right, nothing. No overhead. The only reason C++ code can be slower than C code is if you abuse it, and granted it is easy to abuse... but you don't have to (BTW when I say C++ code I mean using the object-oriented extensions of C++... in other ways C++ is really just a superset of C). Want proof? In later articles you'll have proof yourself with the example source (which for the people who read my 3D articles, you'll be happy to know that this time the example source is already written). But for now, let me give you an example. I have a program called PROCTEST.CPP which is the main file of a project. Inside this program there is one "routine" declared which is a function set framework used for a repeated operation; this routine happens to be a set of empty functions, so they do nothing. An instance of this routine is created by declaring a "process", which is a class that takes a routine frame to tell it what it's supposed to do, and this process is set to "spawn" on the execution of a particular "event", a linked-list structure holding sets of manual spawn and kill orders. Events can be rigged to certain things like music sync points or other process kills, but in this case, the event is executed directly. The spawned process is now added to the process execution queue, and this queue is executed every frame by checking all processes in the queue, getting current timing information for each, (built-in profiling), and executing the process' prime functions, checking for any hooked events or internal self-kills from the process. Another process is created from another routine frame, but this routine does something; it quits the program if a key is pressed. This process is also set to spawn at the initial event, so during the main process queue cycle, both an empty process and a key-quit process are being run, as well as all the other empty slots in the queue being checked for validity information. Sound confusing? That's okay. Sound huge? Understandable. Sound object oriented? Extremely. Wanna know how long it takes to execute a frame, built-in-profiling-multi-process-execution and all? On my P75 at work, 0.000244 seconds, under Win95 even. This is an accurate timing, as I'm reading the PIT directly (< 900ns granularity) which is not affected by Win95's timing quirks except to point out that normal interrupt latency exists (i.e. without interrupts the result would be even better than it already is!). So if you want to complain about overhead, you're complaining about the wrong thing. We're talking about a small fraction of a screen clear's worth of clock cycles, for something that on the outside might appear "bloated and slow". If you want to spend your time complaining about clock cycle loss, optimize your polygon routines more... but don't go whining that C++ is inherently slow; you'd be barking up the wrong tree and only doing yourself a disservice. How you _use_ the language is what counts. There, now that that's said... _____So What Exactly Are We Planning To Do? I'm planning to cover this development process piece by piece, first with how to arrange for large projects, followed by naming conventions, and then on to starting the library itself. Once you get the hang of how the system works, the library's internals won't matter too much (we'll only be doing a few of them with this series); you'll be able to use your existing knowledge to fit the pieces together. The internals we will be building here will be the ones you might not have dealt with, namely the process queues and internal console mentioned before... so if you take nothing of the software design process away with you, you'll at least take away two more techniques that one way or another could help you in your coding. I'll also be going over some of the nuances of using C++ for you C folks here as we go on; there's really not as much to learn as you might think. This series will undoubtedly spread over many articles, but unlike my 3D series there's no rigid "this article this topic" structure or timeline (which should make Snowman happy as far as size limits go :) I don't plan on the series lasting forever, but there might be a few weeks between subsequent articles to compensate for the fact that I have a job to deal with too (still, there shouldn't be too much lag... the code's already done this time, and the article-writing time isn't nearly as long as the code- writing time, so we should be in good shape). BTW, all my code will be written for Watcom C++ 10.0+, so when you see code or makefile references, that's what I'm using. Any specific stuff to the compiler though should be minimal, and besides as I said before, it's the principles that matter. Well, now that I've taken up half my article space for this opening volume, we might as well begin... :) _____Setting Up for Large Projects There are several principles that come in handy when you want to move from a small project arrangement to a large project one. 1. Multiple Directories and/or Version Control If more than one person is working on the project, Version Control software is a good idea, whether you make it yourself or get some kind of actual VCS package like RCS or MS SourceSafe (BTW I highly recommend SourceSafe for you MSVC developers out there). Version Control lets you "check out" files from a particular project, edit them, and check them back in when you're done... that way no two people are editing the files at the same time. It can get nasty if two people are updating a module and one person is making additions to an older version than another person has, and when the updates are completed the stuff from the older version remains while other newer version changes by other people are wiped out. Version Control prevents this from happening. If you're a single person, Version Control might also be helpful to you, but if you don't have it, then you'll want something else to help structure where your files are located (as there is no package present to manage the locations for you like VCS will), such as multiple source directories. Breaking down your project into multiple subdirectories for individual components can help assist in making changes and updates, as you always know where your code for a given type of module should be. 2. Make Use of Library Files The .LIB extension seems all too uncommon these days, but it can be very helpful. For one, projects using a common .LIB will not link with any dead code from the library; only the functions used will be linked in (for you Pascal folks, this basically means use units extensively). In addition, the .LIB can then be a project in itself, so any of the code meant for the library can be kept in the library project _only_ and nowhere else, allowing you to keep track of where you should make changes. Not to mention that if the the .LIB is a project, then when this project is updated and other projects are meant to use the .LIB, all that's required is a relink by the other projects, and everything is new and fresh. 3. Use IDE Projects and/or Makefiles If you have an IDE associated with your compiler that supports projects, take advantage of it. If you don't (or you just don't want to use it, like in the case of Watcom's Windows IDE which I despise), and makefiles are supported, use them. Even better, in the case of projects that use common resources (like a common .LIB as mentioned above), you can set up a single makefile with variables that can be changed on the command line for individual projects. As an example, my arrangement has a subdirectory \PROJECTS, with a single makefile PROJECTS.MAK. Each project I make goes underneath this directory, and they all build with ..\PROJECTS.MAK, so there's only one makefile to change if changes are required. 4. Use Generators Generator programs, such as programs to generate a class frame with a particular name or "buildme" batch file for a particular project, only take a few minutes to write yet can save you an incredible amount of time and headache. In the case of the above PROJECTS.MAK example, having a small program called NEWPROJ that creates a project directory and writes a batch file "BUILDME.BAT" in the dir with the line "wmake /f ..\projects.mak TARGET=(command line param)" is quick and simple to write, but saves a nice chunk of time in the long run. For module frames, doing a similar program that writes an entire module template with a specific name saves tons of grunt work cut&paste time, and by the same token gives you a common frame to work with so your code is consistent. I wrote my class frame generator in 15 minutes, but I'm positive it's saved me at least 5 hours of grunt work time by now. :) 5. Have Effective Naming Conventions This last one is a topic unto itself, which I'll get to next time. Having some kind of standard way to name your variables, functions, and structures may seem too "nitpicky" or "anal" at first, but it can save you phenomenal headache over time, ESPECIALLY if there's more than one person involved in the project. I'll get into specifics in the next volume. _____Conclusion Welp, my space has run out, so I'm taking off. Next time we'll discuss all the ins and outs of good coding style and naming conventions, and why no matter what convention you choose, you should choose one. Until then, :) Chris Hargrove a.k.a. Kiwidog/Terraformer,Hornet alumni Technology Programmer, Raven Software Disclaimer: These articles are in no way affiliated with Raven Software, and represent the views and opinions of the author solely. ----------------------------------------------------------------------------> :: "Ratings - What Does It All Mean?" :: Phoenix / Hornet - phoenix@hornet.org _____Introduction Ratings - What Does It All Mean? Ever since last year, we at the Hornet Archive have been stamping a little rating onto each demo, song, musicdisk, artwork, and sometimes even coding util that gets uploaded. These ratings have certainly helped people in deciding which releases are the "best" and which to not waste their time downloading, but at the same time they've been a source of controversy and confusion. Assuming you've cared at all, you've probably asked yourself "what do all these stars and other weird ratings mean?" Well, here's your humble demo reviewer to attempt an answer to that, with my personal scale for demos. _____The Scale + - Total crapola. Offensive. A bad joke. Why did you make me watch this? * - Ugly. Lame. An average joke. *+ - A really poorly done serious demo. Effects from 1991, bad gabber, no design. Or, a pretty good joke demo. :) ** - Still below par. Old/overdone effects, unfitting music, little to no gfx. **+ - Mediocre. May have some modern effects, but poorly used. Music could use some improvement. *** - Decent/slightly above par. The minimum of what I'd expect from current demos. The music is listenable and fits with the demo. Has modern effects, but some may be overdone. Some OK gfx. ***+ - Very good. May have a new effect or two. There's some design with graphics and transitions. "Catchy" music. I start keeping demos on my hard drive at this level. **** - Excellent. These are usually the smaller party winners. A memorable design/theme with good gfx (if any). Many interesting effects, and high quality, well-synchronized music. I start recommending demos to others at this level. ****+ - Outstanding. I'd only give about 5 or so demos this rating per year. Usually the major party winners, they contain almost all new effects, including one or two ingenious ideas. Well-fitting music once again, and usually top-notch graphics, if not design. ***** - Godlike. I'm saving this for the mother of all demos. After watching several hundred of them, deep inside I still believe that there will be some that make me fall off my chair. [rip] - Uh oh. Contains mostly code/gfx/music that obviously came from another release, but wasn't credited. I've given a couple of these, and deleted one intro that was a complete rip. Boo. [n/a] - Most of the time, this means I could not get the demo to work. My current system is: 486-DX4/75, 8MB RAM, 1MB ET4000 VLB VGA, GUS ACE 512k, and SB Pro. Not too great for recent demos (although I think it should be), but hopefully it will soon be: 6x86/120, 16MB RAM, 2MB S3D PCI VGA. Under various software configurations I can run about 90% of the demos, but my goal is 99% under the new system. (blank) In my departments, party results and pictures do not get rated; graphics programs and newsletters do not either. _____Factors In Demo Ratings Some of those demo ratings may seem a little more unusual than others, but I have a logical explanation for each one. These are some of the factors that go into the ratings. Music + catchy, well-synchronized, style fits mood of demo - boom chi boom chi rez boom rez chi Code + new effects, creative combination/use of old effects - old effects, and even worse, overused effects (e.g. 2D embossing/ bump, tunnels, polar plasma, polar ANYTHING, lens flare, circling bobs [they may have looked pretty in Caero but they're just bobs :)] strobing vectors, etc.) Design + creativity gets points (e.g. Toasted, Paper). So do transitions, well drawn logos and pictures, and good use of color. - trying to imitate stuff done before, or just not having any design I'm neutral on "thematic" demos (like Craw Prod. stuff). Sometimes they work, sometimes they don't. _____The Hitlist If it was not made clear in DN #135, here's who rates what: /demos, /party - Phoenix (me :) /graphics, /mags - GD /music - a small group of people, who should probably remain anonymous since this directory gets the most threats from ratings. :) JTown is the file mover, however. /code - Gee, I don't think any of us know who rates this. :) Sometimes it's Snowman, sometimes Trixter, it's even been Daredevil before. _____Conclusion Anyway, I hope I helped clear up some confusion in demo ratings. All that is left is confusion in other ratings.. well, I'll leave that to them. :) ----------------------------------------------------------------------------> :: "NAID - Memories" :: White Noise - jeff@ego.psych.mcgill.ca You were at NAID, in 95 or 96? You entered something in a competition there? A song, a graphic, a demo, an intro? Then you can help the Ultimate NAID collection. Have a look at naid.conceptech.qc.ca, the NAID - Memories and help us out by sending in what you submitted. Also, should you have pictures of the party in digital format, or artifacts such as ticket stubs or anything that you think could be nifty to add to this Monument to NAID, please send it over. The ftp site is at ftp.naid.conceptech.qc.ca/incoming/naid Thanks for your help. Long live the memories... White Noise. (used to be in Hornet now lost somewhere in a void between his keyboard and his schoolbooks) ----------------------------------------------------------------------------> :: "Java and Demos" :: 3NO (formerly Vector) / Vinlandia, Tpolm Kanada - jnoel@public.nfld.com Hello again. Last week, I outlined my desire to explore Java as a possible demo platform. Since the publication in DemoNews last week I have received a number of responses, all positive. I have decided that instead of doing a newsletter, I will write a regular column in DemoNews on the subject, most likely every 2 weeks or so. Just some brief notes for this week. I noticed on cspid (C-sped? :) about a week ago mention of a web site with some demo-effects on it. Everybody interested should check this out - it has a number of fire effects, as well as a little starfield, which run directly in the web browser. You can find this at http://www.uni-koblenz.de/~cohnen. It's a good example of what can be achieved even at this early stage. Also, one of the best sources of general Java information is the Sun Javasoft site, http://www.javasoft.com. This contains various tutorials and docs, including a complete outline of the High-level Java language and the Java virtual-machine (JVM) specification. This brings up an important point - I would like to start keeping track of sources of demo-oriented Java sites, and will hopefully put up an index site at some point. If anyone knows of any good sites, please email me. The next thing I would like to talk about is Java music-playing. I was talking to Mikmak on irc the other day, and he seemed quite interested in the possibilities of Java, despite some of the shortcomings. (NO unsigned types - argh!). He is apparently working towards a Java version of mikmod, and told me that Rao has been playing with as well. In any event, if music can indeed be played properly in Java, we could be seeing a few basic demos being produced in the near future. A Java tracker could also be interesting - portability is assured, and would be a step towards more direct, on-line co-op composition. Makes me think of that little blurb on the Kosmic web-page. :) The last thing I want to mention is the whole issue of Windows 95 and DirectX demos. Part of the reason I want to start exploring Java as a demo platform is because of Windows 95 and DirectX. I feel DOS is gradually losing it's relevance, and I also think it would be horrible if we all started making Win95 and DirectX demos. As one person on cspid said, it wouldn't be about finding new tricks but finding bugs in the OS, and from my own experiences with Windows programming I have to concur. I think Java is a much more exciting platform for demos, because it is virtually uncharted territory. Besides, there's no reason why Java in the future couldn't support all the accelerated hardware that DirectX is supposed to. Well, this is all I have for this week, and my next column will be 2 weeks from now, hopefully. Have a good holiday, and make sure to email me if you have any feedback, info, or good ideas. ----------------------------------------------------------------------------> :: "Hornet Archive and Jukebox Truth" :: David Greenman _____Introduction When the Hornet Archive started running out of room, one of the suggestions people made over and over again was to have a CD jukebox on wcarchive for additional storage. I tried explaining why this was a bad idea, but people wouldn't listen. Here with us today is David Greenman, official maintainer of ftp.cdrom.com (wcarchive). _____The Scoop > David, could you write a 3-4 paragraph summary of why using online CDROMs > as additional storage for wcarchive is not feasible? I've have been > getting asked this over and over again. As much as I try to explain about > slow seek times, bad performance in multi-user environments, etc., your > words would carry much more weight. Here are a few of the reasons: 1. [most important] The archives change too frequently (usually daily), and this makes permanent storage impractical. 2. We don't have physical access to the machine without an hour's drive to San Francisco; see #1. We don't pay CRL for micro-management of the machine, and co-location is the only way we can afford to provide the level of service that we do. Getting them to insert one or two CDROM's a month is perhaps possible, but one a day (or even one a week) is not. 3. Single CDROM drives are expensive in the MB/drive area - much more expensive than hard drives. While juke boxes bring this price down considerably, we can't use them because they are designed for single- reader access, not 500-reader access. I'm afraid that the little carousel would really be a spinnin'. :-) ...and people would see about 512 byte per 10 seconds transfer rates. You could argue that some archives don't change (like releases of software, for instance), but even for those, we simply have no archives that are trafficked so infrequently that #3 wouldn't kill you every time. Archives that are so unpopular where #3 wouldn't be a problem would (should) be deleted since they don't contribute significantly to the value of the archive. Of course there is also the problem that, while specific software releases don't change, new ones do come out occasionally and the sum total of all new software releases that are put up on wcarchive each day would still make #1/#2 a show-stopper. David Greenman Core-team / Principal Architect, The FreeBSD Project ----------------------------------------------------------------------------> :: "A Demo Scene Survey" :: Nick - stilgar@crush.wwnet.net [Editor's note: You won't believe how much trouble I had in printing this text. Nick emails me a survey (for a class project), I fill it out, send it back, and promise to put a copy in DemoNews. Then I lost the survey. Then the deadline passed. Finally, Nick decided that he'd would persue the project outside of school and could extend the deadline. So here we go.] _____Introduction Note: I realize that time is limited, so if you don't feel like answering all the questions, don't; the first two and the demographics would be nice, or maybe just skip the first five, and head straight into the multiple choice. _____Essay Questions 1. What does the scene mean to you? 2. In your mind, what is the best quality of the scene? 3. What is your favorite demo? Why? 4. What first interested you about the scene? Or, how did you first learn about/get into/whatever the scene? 5. Do you see Microsoft as a necessary evil, or just evil? ;) _____Multiple Choice 6. Do you think the scene will shed its underground? roots? A. Yes. B. No. C. I hope not! 7. Do you think the scene will ever be superseded by larger (perhaps corporate) interests? A. Maybe. B. No way! C. Why are you asking this? 8. By the year 2000, do you think the scene will have: A. Grown immensely B. Grown, but not by an extreme margin C. Stayed roughly the same size D. Started to die out E. Become a force to reckon with 9. By the year 2000, how do you see your relationship with the scene? A. Still immersed in the wonderful world of demos. B. Reduced role. C. Casual Observer. D. Moved on to other things. 10. How do you plan to use your experience in the demo scene to support yourself later in life (or how *did* your experience..) A. Go into business for myself. B. Find a job in a related computer industry. C. It has really just been a hobby. D. I plan on using the experience to change the computing status quo. _____Demographic Information (optional) Age: Country: Group: _____Conclusion When you are done, please cut out this survey from DemoNews and mail it to stilgar@crush.wwnet.net. Thank you for your time. ----------------------------------------------------------------------------> :: "The #trax Page" :: b0b / Chill, Ultrabeat, Mazurka - b0b@datex.ca There's this little page out here on the www called the #trax page. It's the semi official home of all the people who frequent the IRC channel, #trax. In recent times, people beyond the scope of the #trax culture have also logged onto the page and added their entries. It has become more of a demoscene megalink page now. The page gives people the ability to edit their own entries; most people log onto the page to modify their bio's on a regular basis so the page stays very up to date for the most part. Or so that's the theory. :) Currently the page has over 340 people listed, over 150 pictures of scene people, and about 20+ group listings (and growing). One of the newest features of the page gives everyone the ability to add/edit and delete 'releases' to their bio's. Your releases can be hyperlinked to an FTP or HTTP server where the file might be stored. This feature although VERY cool has not really caught on. :( So let's see you people adding in your releases!!! Recent updates include: - fixed links section (took out pictures, looks nicer now). - fixed some source code bugs that no one else really noticed. - added about 15 new pics and updated about 10 other pics. - added about 4 new groups. - shrunk the damn logo so that it doesn't take nearly as long to load now. - fixed all the pages so that you can resize them and they don't screw up. Some people may have noticed lately that there were a lack of updates. The reason being that I got very busy at my "real job". Luckily things have slowed down due to the X-mas season and I was able to reply to the 100+ messages in my mailbox regarding the page. If there anyone now who has sent me something via e-mail and has not received a reply please resend your message. Lastly, there are still over 100 people who have not logged onto the page to change their default password. On 01 February 1997, I will be deleting all entries that have not updated your password. The default password is: XXXXXX Six x's. So login and change it if you havn't. Thanx. And remember: http://www.spaz.com/trax >------------------------------------------------------- General Information -- _____The Hornet Archive Master Site : USA (California) - (ftp|www).hornet.org/pub/demos Mirrors : Portugal - ftp.telepac.pt/pub/demos Sweden - ftp.luth.se/pub/msdos/demos South Africa - ftp.sun.ac.za/pub/msdos/demos USA (Wisconsin) - ftp.uwp.edu/pub/demos USA (Pennsylvania) - ftp.co.iup.edu/code (from /demos/code) _____DemoNews New issues are posted to /incoming/info. Old issues are in /info/demonews. Supplemental files are in /info/dn_other. How to subscribe: Mail - listserver@unseen.aztec.co.za Body - subscribe demuan-list FIRST_NAME LAST_NAME _or_ Body - subscribe demuan-list HANDLE DemoNews is sent to your e-mail's "Reply-To" field. _____Contact Address questions@hornet.org >------------------------------------------------------------------------------ EODN